Oftentimes, it is desirable to upgrade a format of a cluster file system to enhance or enable one or more features of the file system. In particular, one might be interested in extending the capacity of files that may be stored within the file system by upgrading the version of a file system from a 32-bit file address format to a 64-bit file address format. Typically, in order to upgrade a 32-bit file address format to a 64-bit file address format, the address of each file included in the file system is padded with thirty-two zeros to make them compatible with the new, 64-bit address format that is expected by any entity performing input/output (IO) operations to the file system. In addition, bit map data structures will have to be expanded to track additional file blocks that can be addressed with the 64-bit file address format.
Presently, performing such upgrades to existing file systems requires that they first be taken “offline,” i.e., to a state where all IO activity associated with the file system is stopped. For example, all popular cluster file systems—such as Redhat-GFS, IBM-GPFS, Symantec-CFS, Oracle Solaris GFS, and/or Oracle-OCFS—each require that all IO activity associated with the file system be stopped prior to being upgraded. This is necessary to prevent IO operations being made to the file system during the upgrade process, which could potentially result in corruption.
However, taking a file system offline prevents any entity from accessing the file system until the upgrade to the file system is completed and the file system is brought back online. Further, the latency associated with taking a file system offline is often high due to several tasks that must first be completed. For example, if the file system is stored locally on a desktop computer, all IO operations are first completed, then all open files in the file system are closed. The file system is then unmounted from any entities that are accessing the file system. In another example, if the file system is accessed by one or more virtual machines (VMs) executing on a server, virtual disks of the running VMs, which may be stored as large files in the file system, must be migrated to a different file system on an auxiliary disk to enable the VMs to continue to operate, whereupon the file system is unmounted from the server and the upgrade to the file system is executed. When the upgrade to the file system has completed, the virtual disks are then optionally migrated back from the auxiliary disk. Such auxiliary disk requirements incur “storage bloat” which degrades, e.g., VM migrations, and increase costs to customers.
As a consequence, such current techniques for upgrading a cluster file system impose a significant inconvenience for services that require their file systems to be accessible at all times, such as banking software that requires access to transaction data stored on the file system. Therefore, what is needed is a way to perform an online, in-place upgrade to a file system in an efficient and non-intrusive manner.